片断|之和_浅析现代Web端im即时通讯开发技术

篇首语：本文由编程笔记#小编为大家整理，主要介绍了浅析现代Web端im即时通讯开发技术相关的知识，希望对你有一定的参考价值。

传统的Web端即时通讯技术从短轮询到长连询&＃xff0c;再到Comet技术&＃xff0c;在如此原始的html标准之下&＃xff0c;为了实现所谓的“即时”通信&＃xff0c;技术上可谓绞尽脑汁&＃xff0c;极尽所能。

自从HTML5标准发布之后&＃xff0c;WebSocket这类技术横空出世&＃xff0c;实现Web端即时通讯技术的便利性大大提前&＃xff0c;以往想都不敢想的真正全双工实时通信&＃xff0c;如此早已成为可能。

在这里不打算详细介绍整个WebSocket协议的内容&＃xff0c;根据我本人以前协议的学习思路&＃xff0c;我挑重点使用问答方式来介绍该协议&＃xff0c;这样读起来就不那么枯燥。

协议运行在OSI的哪层&＃xff1f;

应用层&＃xff0c;WebSocket协议是一个独立的基于TCP的协议。 它与HTTP唯一的关系是它的握手是由HTTP服务器解释为一个Upgrade请求。

协议运行的标准端口号是多少&＃xff1f;

默认情况下&＃xff0c;WebSocket协议使用端口80用于常规的WebSocket连接、端口443用于WebSocket连接的在传输层安全&＃xff08;TLS&＃xff09;RFC2818之上的隧道化口。

协议是如何工作的?

其中帧的一些重要字段需要解释一下&＃xff1a;

    1&＃xff09;Upgrade&＃xff1a;&＃96;upgrade&＃96;是HTTP1.1中用于定义转换协议的&＃96;header&＃96;域。它表示&＃xff0c;如果服务器支持的话&＃xff0c;客户端希望使用现有的「网络层」已经建立好的这个「连接&＃xff08;此处是 TCP 连接&＃xff09;」&＃xff0c;切换到另外一个「应用层」&＃xff08;此处是 WebSocket&＃xff09;协议&＃xff1b;

    2&＃xff09;Connection&＃xff1a;&＃96;Upgrade&＃96;固定字段。Connection还有其他字段&＃xff0c;可以自己给自己科普一下&＃xff1b;

    3&＃xff09;Sec-WebSocket-Key&＃xff1a;用来发送给服务器使用&＃xff08;服务器会使用此字段组装成另一个key值放在握手返回信息里发送客户端&＃xff09;&＃xff1b;

    4&＃xff09;Sec-WebSocket-Protocol&＃xff1a;标识了客户端支持的子协议的列表&＃xff1b;

    5&＃xff09;Sec-WebSocket-Version&＃xff1a;标识了客户端支持的WS协议的版本列表&＃xff0c;如果服务器不支持这个版本&＃xff0c;必须回应自己支持的版本&＃xff1b;

    6&＃xff09;Origin&＃xff1a;作安全使用&＃xff0c;防止跨站攻击&＃xff0c;浏览器一般会使用这个来标识原始域&＃xff1b;

    7&＃xff09;Sec-WebSocket-Accept&＃xff1a;服务器响应&＃xff0c;包含Sec-WebSocket-Key 的签名值&＃xff0c;证明它支持请求的协议版本。

关于Sec-WebSocket-Key和Sec-WebSocket-Accept的计算是这样的&＃xff1a;

    所有兼容RFC 6455 的WebSocket 服务器都使用相同的算法计算客户端挑战的答案&＃xff1a;将Sec-WebSocket-Key 的内容与标准定义的唯一GUID字符(258EAFA5-E914-47DA-95CA-C5AB0DC85B11)串拼接起来&＃xff0c;计算出SHA1散列值&＃xff0c;结果是一个base-64编码的字符串&＃xff0c;把这个字符串发给客户端即可。

用代码就是实现如下&＃xff1a;

    const key &＃61; crypto.createHash(&＃39;sha1&＃39;)

    .update(req.headers[&＃39;sec-websocket-key&＃39;] &＃43; constants.GUID, &＃39;binary&＃39;)

    .digest(&＃39;base64&＃39;)

引用如下&＃xff1a;

    Sec-WebSocket-Key/Sec-WebSocket-Accept在主要作用在于提供基础的防护&＃xff0c;减少恶意连接、意外连接。

作用大致归纳如下&＃xff1a;

    1&＃xff09;避免服务端收到非法的websocket连接&＃xff08;比如http客户端不小心请求连接websocket服务&＃xff0c;此时服务端可以直接拒绝连接&＃xff09;&＃xff1b;

    2&＃xff09;确保服务端理解websocket连接。因为ws握手阶段采用的是http协议&＃xff0c;因此可能ws连接是被一个http服务器处理并返回的&＃xff0c;此时客户端可以通过Sec-WebSocket-Key来确保服务端认识ws协议。&＃xff08;并非百分百保险&＃xff0c;比如总是存在那么些无聊的http服务器&＃xff0c;光处理Sec-WebSocket-Key&＃xff0c;但并没有实现ws协议。。。&＃xff09;&＃xff1b;

    3&＃xff09;用浏览器里发起ajax请求&＃xff0c;设置header时&＃xff0c;Sec-WebSocket-Key以及其他相关的header是被禁止的。这样可以避免客户端发送ajax请求时&＃xff0c;意外请求协议升级&＃xff08;websocket upgrade&＃xff09;&＃xff1b;

    4&＃xff09;可以防止反向代理&＃xff08;不理解ws协议&＃xff09;返回错误的数据。比如反向代理前后收到两次ws连接的升级请求&＃xff0c;反向代理把第一次请求的返回给cache住&＃xff0c;然后第二次请求到来时直接把cache住的请求给返回&＃xff08;无意义的返回&＃xff09;&＃xff1b;

    5&＃xff09;Sec-WebSocket-Key主要目的并不是确保数据的安全性&＃xff0c;因为Sec-WebSocket-Key、Sec-WebSocket-Accept的转换计算公式是公开的&＃xff0c;而且非常简单&＃xff0c;最主要的作用是预防一些常见的意外情况&＃xff08;非故意的&＃xff09;。

强调&＃xff1a;Sec-WebSocket-Key/Sec-WebSocket-Accept 的换算&＃xff0c;只能带来基本的保障&＃xff0c;但连接是否安全、数据是否安全、客户端/服务端是否合法的 ws客户端、ws服务端&＃xff0c;其实并没有实际性的保证。即时通讯开发

协议传输的帧格式是什么?

各个字段的解释如下&＃xff1a;

    1&＃xff09;FIN&＃xff1a; 1bit&＃xff0c;用来表明这是一个消息的最后的消息片断&＃xff0c;当然第一个消息片断也可能是最后的一个消息片断&＃xff1b;

    2&＃xff09;RSV1&＃xff0c;RSV2&＃xff0c;RSV3&＃xff1a; 分别都是1位&＃xff0c;如果双方之间没有约定自定义协议&＃xff0c;那么这几位的值都必须为0,否则必须断掉WebSocket连接。在ws中就用到了RSV1来表示是否消息压缩了的&＃xff1b;

    3&＃xff09;opcode&＃xff1a;4 bit&＃xff0c;表示被传输帧的类型&＃xff1a;

    - %x0 表示连续消息片断&＃xff1b;

    - %x1 表示文本消息片断&＃xff1b;

    - %x2 表未二进制消息片断&＃xff1b;

    - %x3-7 为将来的非控制消息片断保留的操作码&＃xff1b;

    - %x8 表示连接关闭&＃xff1b;

    - %x9 表示心跳检查的ping&＃xff1b;

    - %xA 表示心跳检查的pong&＃xff1b;

    - %xB-F 为将来的控制消息片断的保留操作码。

    4&＃xff09;Mask&＃xff1a; 1 bit。定义传输的数据是否有加掩码,如果设置为1,掩码键必须放在masking-key区域&＃xff0c;客户端发送给服务端的所有消息&＃xff0c;此位都是1&＃xff1b;

    5&＃xff09;Payload length&＃xff1a;传输数据的长度&＃xff0c;以字节的形式表示&＃xff1a;7位、7&＃43;16位、或者7&＃43;64位。如果这个值以字节表示是0-125这个范围&＃xff0c;那这个值就表示传输数据的长度&＃xff1b;如果这个值是126&＃xff0c;则随后的两个字节表示的是一个16进制无符号数&＃xff0c;用来表示传输数据的长度&＃xff1b;如果这个值是127,则随后的是8个字节表示的一个64位无符合数&＃xff0c;这个数用来表示传输数据的长度。多字节长度的数量是以网络字节的顺序表示。负载数据的长度为扩展数据及应用数据之和&＃xff0c;扩展数据的长度可能为0,因而此时负载数据的长度就为应用数据的长度&＃xff1b;

    6&＃xff09;Masking-key&＃xff1a;0或4个字节&＃xff0c;客户端发送给服务端的数据&＃xff0c;都是通过内嵌的一个32位值作为掩码的&＃xff1b;掩码键只有在掩码位设置为1的时候存在&＃xff1b;

    7&＃xff09;Extension data&＃xff1a; x位&＃xff0c;如果客户端与服务端之间没有特殊约定&＃xff0c;那么扩展数据的长度始终为0&＃xff0c;任何的扩展都必须指定扩展数据的长度&＃xff0c;或者长度的计算方式&＃xff0c;以及在握手时如何确定正确的握手方式。如果存在扩展数据&＃xff0c;则扩展数据就会包括在负载数据的长度之内&＃xff1b;

    8&＃xff09;Application data&＃xff1a; y位&＃xff0c;任意的应用数据&＃xff0c;放在扩展数据之后&＃xff0c;应用数据的长度&＃61;负载数据的长度-扩展数据的长度&＃xff1b;

    9&＃xff09;Payload data&＃xff1a; (x&＃43;y)位&＃xff0c;负载数据为扩展数据及应用数据长度之和&＃xff1b;

更多细节请参考RFC6455-数据帧&＃xff0c;这里不作赘述。

针对上面的各个字段的介绍&＃xff0c;有一个Mask的需要说一下。

掩码键&＃xff08;Masking-key&＃xff09;是由客户端挑选出来的32位的随机数。掩码操作不会影响数据载荷的长度。

掩码、反掩码操作都采用如下算法。

首先&＃xff0c;假设&＃xff1a;

    1&＃xff09;original-octet-i&＃xff1a;为原始数据的第i字节&＃xff1b;

    2&＃xff09;transformed-octet-i&＃xff1a;为转换后的数据的第i字节&＃xff1b;

    3&＃xff09;j&＃xff1a;为i mod 4的结果&＃xff1b;

    4&＃xff09;masking-key-octet-j&＃xff1a;为mask key第j字节。

算法描述为&＃xff1a; original-octet-i 与 masking-key-octet-j 异或后&＃xff0c;得到 transformed-octet-i。

即&＃xff1a; j &＃61; i MOD 4 transformed-octet-i &＃61; original-octet-i XOR masking-key-octet-j

用代码实现&＃xff1a;

    const mask &＃61; (source, mask, output, offset, length) &＃61;>

    for(vari &＃61; 0; i

    output[offset &＃43; i] &＃61; source[i ] ^ mask[i & 3];

    ;

解掩码是反过来的操作&＃xff1a;

    const unmask &＃61; (buffer, mask) &＃61;>

    // Required until [url&＃61;https://github.com/nodejs/node/issues/9006]https://github.com/nodejs/node/issues/9006[/url] is resolved.

    const length &＃61; buffer.length;

    for(vari &＃61; 0; i

    buffer[i ] ^&＃61; mask[i & 3];

    ;

同样的为什么需要掩码操作&＃xff0c;也可以参考之前的那篇文章&＃xff1a;《理论联系实际&＃xff1a;从零理解WebSocket的通信原理、协议格式、安全性》&＃xff0c;完整的我就不列举了。

需要注意的重点&＃xff0c;我引用一下&＃xff1a;

    WebSocket协议中&＃xff0c;数据掩码的作用是增强协议的安全性。但数据掩码并不是为了保护数据本身&＃xff0c;因为算法本身是公开的&＃xff0c;运算也不复杂。除了加密通道本身&＃xff0c;似乎没有太多有效的保护通信安全的办法。

    那么为什么还要引入掩码计算呢&＃xff0c;除了增加计算机器的运算量外似乎并没有太多的收益&＃xff08;这也是不少同学疑惑的点&＃xff09;。

    答案还是两个字&＃xff1a; 安全。但并不是为了防止数据泄密&＃xff0c;而是为了防止早期版本的协议中存在的代理缓存污染攻击&＃xff08;proxy cache poisoning attacks&＃xff09;等问题。

传统Web长连接的技术实现背景

在现实的Web端产品中&＃xff0c;并不是所有的Web客户端都支持长连接的&＃xff0c;或者换句话说&＃xff0c;在WebSocket协议出来之前&＃xff0c;是三种方式去实现WebSocket类似的功能的。

这三种方式是&＃xff1a;

    1&＃xff09;Flash&＃xff1a;使用Flash是一种简单的方法。不过很明显的缺点就是Flash并不会安装在所有客户端上&＃xff0c;比如iPhone/iPad。

    2&＃xff09;Long-Polling&＃xff1a;也就是众所周之的“长轮询”&＃xff0c;在过去&＃xff0c;这是一种有效的技术&＃xff0c;但并没有对消息发送进行优化。虽然我不会把AJAX长轮询当做一种hack技术&＃xff0c;但它确实不是一个最优方法&＃xff1b;

    3&＃xff09;Comet&＃xff1a;在过去&＃xff0c;这被称为Web端的“服务器推”技术&＃xff0c;相对于传统的 Web 应用&＃xff0c; 开发 Comet 应用具有一定的挑战性&＃xff0c;具体请见《Comet技术详解&＃xff1a;基于HTTP长连接的Web端实时通信技术》。

那么如果单纯地使用WebSocket的话&＃xff0c;那些不支持的客户端怎么办呢&＃xff1f;难道直接放弃掉&＃xff1f;

当然不是。Guillermo Rauch大神写了socket.io这个库&＃xff0c;对WebSocket进行封装&＃xff0c;从而让长连接满足所有的场景&＃xff0c;不过当然得配合使用对应的客户端代码。

socket.io将会使用特性检测的方式来决定以websocket/ajax长轮询/flash等方式建立连接。

那么socket.io是如何做到这些的呢&＃xff1f;

我们带着以下几个问题去学习&＃xff1a;

    1&＃xff09;socket.io到底有什么新特性&＃xff1f;

    2&＃xff09;socket.io是怎么实现特性检测的&＃xff1f;

    3&＃xff09;socket.io有哪些坑呢&＃xff1f;

    4&＃xff09;socket.io的实际应用是怎样的&＃xff0c;需要注意些什么&＃xff1f;

如果有童鞋对上述问题已经清楚&＃xff0c;想必就没有往下读的必要了。

5.3 socket.io的介绍

通过前面章节&＃xff0c;读者们都知道了WebSocket的功能&＃xff0c;那么socket.io相对于WebSocket&＃xff0c;在此基础上封装了一些什么新东西呢&＃xff1f;

socket.io其实是有一套封装了websocket的协议&＃xff0c;叫做engine.io协议&＃xff0c;在此协议上实现了一套底层双向通信的引擎Engine.io。

而socket.io则是建立在engine.io上的一个应用层框架而已。所以我们研究的重点便是engine.io协议。

在socket.io的README中提到了其实现的一些新特性&＃xff08;回答了问题一&＃xff09;&＃xff1a;

    1&＃xff09;可靠性&＃xff1a;连接依然可以建立即使应用环境存在&＃xff1a; 代理或者负载均衡器 个人防火墙或者反病毒软件&＃xff1b;

    2&＃xff09;支持自动连接&＃xff1a; 除非特别指定&＃xff0c;否则一个断开的客户端会一直重连服务器直到服务器恢复可用状态&＃xff1b;

    3&＃xff09;断开连接检测&＃xff1a;在Engine.io层实现了一个心跳机制&＃xff0c;这样允许客户端和服务器知道什么时候其中的一方不能响应。该功能是通过设置在服务端和客户端的定时器实现的&＃xff0c;在连接握手的时候&＃xff0c;服务器会主动告知客户端心跳的间隔时间以及超时时间&＃xff1b;

    4&＃xff09;二进制的支持&＃xff1a;任何序列化的数据结构都可以用来发送&＃xff1b;

    5&＃xff09;跨浏览器的支持&＃xff1a;该库甚至支持到IE8&＃xff1b;

    6&＃xff09;支持复用&＃xff1a;为了在应用程序中将创建的关注点隔离开来&＃xff0c;Socket.io允许你创建多个namespace&＃xff0c;这些namespace拥有单独的通信通道&＃xff0c;但将共享相同的底层连接&＃xff1b;

    7&＃xff09;支持Room&＃xff1a;在每一个namespace下&＃xff0c;你可以定义任意数量的通道&＃xff0c;我们称之为"房间"&＃xff0c;你可以加入或者离开房间&＃xff0c;甚至广播消息到指定的房间。

注意&＃xff1a;Socket.IO不是WebSocket的实现&＃xff0c;虽然 Socket.IO确实在可能的情况下会去使用WebSocket作为一个transport&＃xff0c;但是它添加了很多元数据到每一个报文中&＃xff1a;报文的类型以及namespace和ack Id。这也是为什么标准WebSocket客户端不能够成功连接上 Socket.IO 服务器&＃xff0c;同样一个 Socket.IO 客户端也连接不上标准WebSocket服务器的原因。